Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@api/v1beta1/openstacklightspeed_types.go`:
- Around line 49-50: The MCP sidecar image is still defaulting to a mutable
“latest” tag, which means deployments can drift from the tested binary. Update
the default image constant in openstacklightspeed_types.go and ensure the same
pinned, immutable release image is used in manager.yaml and the generated CSV so
all install and upgrade paths reference the exact released MCP server image.

In `@cmd/main.go`:
- Around line 193-197: The `getDynamicWatchCRDs` call site still treats the
function as returning an error even though it never does, which triggers the
`unparam` lint issue. Update `getDynamicWatchCRDs` to remove the dead error
return, then simplify its callers in `main` and any other affected paths
(including the other mentioned block) to stop checking `err` and just use the
returned CRD value(s) directly.

In `@config/rbac/role.yaml`:
- Around line 15-26: The ClusterRole in role.yaml is granting broad cluster-wide
Secret write/read permissions that override the intended `resourceNames`
restriction for `pull-secret`. Tighten the `secrets` rule in this ClusterRole to
only the minimal cluster-scoped Secret access needed for MCP/Keystone, and move
any Secret create/update/patch/delete permissions to the namespaced Role used
for managed Secrets. Keep the existing `resourceNames`-based access for
`pull-secret` and verify the `ClusterRole` versus `Role` split preserves only
the required external reads.

In `@config/samples/api_v1beta1_openstacklightspeed.yaml`:
- Around line 18-21: The sample has a duplicate commented dev configuration
block that can lead users to create two dev keys when enabling both examples.
Update the OpenStack Lightspeed sample so the rhos_mcps option is folded into
the existing commented dev.featureFlags example rather than adding a second dev
section, using the dev and featureFlags sample entries to keep the structure
unambiguous.

In `@internal/controller/common.go`:
- Around line 292-301: GetDeploymentVolumeSection currently takes
appsv1.Deployment by value, so the returned *corev1.Volume points into a copied
Deployment rather than the caller’s object. Update GetDeploymentVolumeSection to
accept a *appsv1.Deployment (add a nil guard) and return the matching volume
from deployment.Spec.Template.Spec.Volumes so any caller mutation affects the
original Deployment.

In `@internal/controller/mcp_server.go`:
- Around line 794-820: The cleanup in mcp_server.go is deleting broadly named
ConfigMaps/Secrets without verifying they belong to this operator instance,
which can remove pre-existing or user-managed resources; update the deletion
logic around the MCP cleanup block and the related password Secret cleanup to
first check ownership via labels or controller metadata before calling
helper.GetClient().Delete. Use the existing resource symbols
MCPConfigYAMLConfigMapName, CloudsYAMLConfigMapName, SecureYAMLSecretName,
CombinedCABundleSecretName, and the lightspeed-password Secret cleanup path to
ensure only operator-managed objects are removed, especially for the
cross-namespace Secret where owner references may not be safe.
- Around line 514-516: The OpenStack MCP setup flow in mcp_server.go is treating
a Secret as ready even when AC_ID or AC_SECRET are missing, which can write
empty application-credential values into secure.yaml. Update the logic around
the return in the application credential handling path to verify both secret
keys exist and contain non-empty values before marking the secret ready or
returning success; if either key is missing, keep waiting/retrying instead of
proceeding.
- Around line 348-350: The password Secret lookup in mcp_server.go currently
treats any existing Secret as valid, even when LightspeedPasswordSecretName is
present without LightspeedPasswordSecretKey and
string(sec.Data[LightspeedPasswordSecretKey]) becomes empty. Update the
secret-handling logic in the password retrieval path to explicitly verify the
key exists and has a non-empty value before returning it; if the Secret is
missing the key, return an error instead of an empty password so the Keystone
user is not created or reconciled with a blank credential.

In `@internal/controller/openstacklightspeed_controller.go`:
- Around line 162-168: The polling in the OpenStack control flow stops too early
for cross-namespace instances, so readiness and endpoint/CA updates can be
missed after discovery. Update the logic around the `oscpWatch` check in
`openstacklightspeed_controller.go` so `RequeueAfter` continues until a real
cross-namespace watch is established, or add watch coverage for
`OpenStackControlPlane` changes outside the operator namespace; ensure the
reconcile path that handles `OpenStackReady` still requeues or watches the
relevant `OpenStackControlPlane` updates.
- Around line 479-518: Keep the DynamicWatchCRD flag latched once a watch has
been registered in WatchDynamicCRD. The current Reconcile-driven loop in
openstacklightspeed_controller.go clears seen when IsCRDEstablished reports the
CRD is gone, which can allow r.controller.Watch(...) to be registered again
later even though there is no unregister path. Update the logic around the
DynamicWatchCRD/seen handling so a successful watch registration stays marked
true and does not attempt duplicate setup on subsequent reconciles.

In `@test/kuttl/tests/application-credentials/04-assert-mock-openstack.yaml`:
- Around line 4-15: The step timeout is too tight for the commands in the mock
OpenStack assertion script, which can cause flakes when the waits run close to
their limits. Increase the timeout in the test step so the combined `oc wait`
and `oc get` operations in the `commands` block have enough headroom; update the
`timeout` setting in this KUTTL test manifest accordingly.

In `@test/kuttl/tests/application-credentials/06-assert-ac-resources.yaml`:
- Around line 10-42: The wait loops in the application-credentials assertion
script can take longer than the step timeout, so the test may be terminated
before finishing its checks. Update the timeout setting in the same script to
exceed the worst-case combined wait time used by the secret and AC CR polling
loops, and keep the timeout aligned with the logic in the shell block that waits
for lightspeed-password and the
keystoneapplicationcredentials.keystone.openstack.org resource.

In `@test/kuttl/tests/application-credentials/08-assert-mcp-credentials.yaml`:
- Around line 42-64: The checks in the application-credentials KUTTL assertion
script read `openstack-config-secret` and `mcp-config` only once, which can race
with resource availability. Update the verification flow in this test to poll
with retries and short waits before asserting on `SECURE` and `MCP_CFG`,
re-fetching the Secret and ConfigMap until the expected keys are present or a
timeout is reached. Keep the existing `oc get`/`grep` assertions in place, but
wrap them in retry logic so the `clouds.yaml`-driven readiness is handled
reliably.

In `@test/kuttl/tests/application-credentials/12-cleanup-mock-openstack.yaml`:
- Around line 13-15: The teardown in the cleanup step uses a fixed 60-second
wait for namespace deletion, which can make the scenario flaky on slower
clusters. Update the cleanup logic around the namespace deletion command in the
test to avoid relying on a hard `--timeout=60s`; instead use delete plus polling
for completion, or increase it to a safer bounded wait before removing the CRDs.

In
`@test/kuttl/tests/persistent-database/04-assert-openstack-lightspeed-instance.yaml`:
- Around line 51-52: The OpenStackLightspeedMCPServerReady assertion only checks
for a True status, so it can pass even when the MCP is enabled through an
unintended path. Update the existing assertion in this persistent-database test
to also verify the disabled message, matching the other suite checks, so the
condition is specifically validating the expected disabled-state behavior rather
than any True result.

---

Nitpick comments:
In `@test/kuttl/common/mock-openstack/mock-keystone.yaml`:
- Line 118: The mock Keystone fixture is using a floating image tag, which makes
the KUTTL test environment nondeterministic. Update the image reference in the
mock OpenStack YAML to a pinned version or digest instead of
registry.redhat.io/ubi8/python-311:latest, keeping the mock setup reproducible
across CI runs.

In `@test/kuttl/common/mock-openstack/mock-oscp-resources.yaml`:
- Around line 84-86: The mock OpenStackControlPlane status only sets
status.tls.caBundleSecretName, so the readiness-gated path in the MCP enablement
flow is never exercised. Update the mock status fixture used by
OpenStackControlPlane to include a ready condition in addition to the TLS
bundle, using the existing OpenStackControlPlane status shape so the KUTTL
scenario can assert both pre-ready and post-ready behavior if needed.

In `@test/kuttl/tests/rhos-mcps-configuration/04-disable-rhos-mcps.yaml`:
- Around line 21-22: Add an explicit assertion after disabling the feature flag
to verify the sidecar is removed from the deployment. Update the KUTTL scenario
around the rhos-mcps toggle so it checks that lightspeed-stack-deployment no
longer contains rhos-mcp, in addition to the existing mcp-config cleanup
validation, to catch regressions in the disable path.